Merge train: #9899, #9900, #9902 - #9903

Merge train: #9899, #9900, #9902.

Two of these close issues filed while auditing earlier trains.

#9899 — module namespace data descriptors (#9889)

#9879 made aliased dynamic-import bindings live, and implemented that by installing them as accessor properties, so Object.getOwnPropertyDescriptor(ns, "x") reported get/set where ECMA-262 §10.4.6.5 and Node report a data descriptor. #9899 takes the option that keeps both: accessors remain the internal representation of the live binding, and the namespace's [[GetOwnProperty]] synthesises { value, writable: true, enumerable: true, configurable: false } over it.

The rooting is right — namespace and key are held across js_object_get_field_by_name, which runs the getter and can allocate and evacuate — and the doc comment says so.

Its new gap-test assertions cover exactly what the issue named: "value" in descriptor, all three attributes, get/set both undefined, and the value still live across a reassignment. Being a gap test, Node is the oracle for the shape.

#9902 — for-in visited levels across GC (#9869)

The regression fixture #9869 was left open for: a three-level prototype chain where the middle level contributes no enumerable keys, so the shadow set stays deferred and build_shadow_set reads both retained levels after the key-array allocations have moved them. Runs under PERRY_GC_SCHEDULE_RATE=1 with forced evacuation, evacuation verification and from-space protection.

One note for the maintainer, not changed here: the fixture is named test_issue_9869_…, and the per-PR gap-suite shards select on the substring test_gap_, so this runs in the nightly full tier only. That matches the convention of the other 380 test_issue_* files, so it is not a defect in this PR — but a GC rooting regression is the case where per-PR coverage is worth most, since the whole failure mode is staying invisible until much later. Renaming it test_gap_issue_9869_… would move it into the per-PR gate; that is a test-tier policy call rather than a merge blocker.

#9900 — dead string-wrapper counter

STRING_WRAPPERS was declared and read but never incremented, so it always reported zero behind an if wrappers > 0 guard that never fired. Removed along with its holder-inventory entry — the paired change the gate requires, since a stale entry fails it. The surrounding comment also stops claiming the diagnostic counts "wrappers actually materialised", which it never did.

Validation

run_lint_gates: all 64 gates passed; 2 CI-only skipped